System Area Networks (SANs) provide significant benefits as compared to other network configurations. Typical SANs are highly localized having multiple server or host computer systems communicating with each other and sharing one or more storage subsystems and possibly tape, optical or other backup media changers. Additionally, many SANs have multiple host computer systems that may be used to perform several different but complimentary functions. For example, one host computer system may be used for end-user applications while a second host computer system may be used to perform background, administration type functions such as backing up end-user application data or other system data or for performing extended query resolution on large databases of information. Using two host computer systems in such a manner significantly improves the performance of the system since the two may operate substantially in parallel.
One issue that arises when configuring a SAN to utilize two or more host computer systems to operate in parallel relates to the sharing of the data used by each host computer system. That is, the end-user host computer system may require access to a specific volume of information stored either locally on its own computer system or on a storage subsystem that is connected to the SAN. The storage subsystem may have an extensive amount of storage capabilities and may in fact provide storage for many other host computer systems in the SAN. Additionally however, the specific volume requested by the first host computer system may also be needed by the second host computer system in order to perform its functions. Such conflicts typically need to be resolved in order for both host computer systems to access the information and to operate in a more optimal manner.
Of particular concern is the case where the second computer system requires a relatively exact, read-only copy of all the data on a volume of information. A volume relates to portions of memory that have been logically combined and presented to a host computer system such that the host computer system views the volume as one portion of memory, e.g., a single disk or a single drive of information.
One solution to this problem involves the first computer system sending all the information, over the network, to the second computer system. Unfortunately however, this method significantly saturates the network and reduces the performance of the network and is therefore unsatisfactory.
A second solution to transferring information relates to the use of a “point-in-time copy” of the data, also referred to as “shadow copies” or “snapshots.” Point-in-time copies are physical copies of data that are created by a storage subsystem. In essence, there are quite of few storage systems that have the capability of quickly and efficiently creating a “mirror” or a point-in-time copy of a portion of the physical storage in their respective systems. The point-in-time copy, therefore, relates to a full physical copy of information stored in another portion of the storage subsystem. Since the point-in-time copy is stored in another portion of the storage subsystem, the second computer system may be provided direct access, without conflict, to the point-in-time copy. Providing access of the point-in-time copy to the second computer system is referred to as transferring ownership of the data from the first computer system to the other computer system, i.e., transporting the content to the second machine.
Creation of a point-in-time copy is done by a storage subsystem, which is typically controlled by a hardware provider. Unfortunately however, hardware providers generally operate at the “LUN” level. A LUN is a Logical Unit Number and relates to a virtual device that is “surfaced” by the storage subsystem. A LUN may correspond to a spindle in the storage subsystem or a set of spindles. From the perspective of the host or host computer system accessing a LUN, the LUN looks like a disk which can be used to construct volumes. Hence, volumes are typically a subset of a LUN, but often, a volume may be spread over various LUNs.
Hardware surfaced point-in-time copies (i.e., copies created with the help of a hardware subsystem) results in the creation of a new LUN for each original LUN of the volume. The new LUN may be a new, full physical copy or may be an existing copy created using copy-on-write technology. Unfortunately however, transportation of data content typically occurs at the LUN level, not at the volume level. That is, although a LUN may be transported separately from the original LUN to a different machine, there is a considerable amount of work that must be done by a receiving computer system to understand what portions of the LUN are relevant, where those items are located, etc.
A common requirement for both these scenarios is to capture what the application data is (i.e., the databases, files, etc.) as well as capture the physical representation of the volumes on which that data resides (i.e., the LUNs). The LUNs and the application data (i.e., how the data is mapped onto the LUNs) need to be surfaced on the machine to which the data is transported. Unfortunately however, hardware mechanisms for creating point-in-time copies operate on the LUN level and therefore there is no way to access data based on volumes that may be spread across several LUNs. Additionally, within a SAN environment, there may be multiple storage subsystems that may be capable of creating point-in-time copies wherein each subsystem is made by different vendors. Unfortunately, in such an environment, each requestor or importer must be aware of specific hardware components for these subsystems in order to import a point-in-time copy.
It is with respect to these and other considerations that the present invention has been made.